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Anomalies in Apollo 14 Descent 


Per Webster, An anomaly is a "deviation from the common rule; irregulari¬ 
ty". There is no suggestion either that the anomaly is a flaw or that it is caused 
by a fault. An anomaly may be a deficiency or produced by a deficiency, or it 
may be merely a deviation from the common rule or norm which is acceptable and 
explicable by a less common, more obscure rule. 

About sixteen such anomalies in Apollo 14 descent simulations are being ex¬ 
amined and analyzed to determine the causes and the corrections required, if any. 
Most anomalies have been traced to sources which cannot affect the mission and 
are not discussed at this time. The remaining anomalies have been traced to the 
Luminary program or the erasable load. Each is listed along with the probable 
cause. The behavior in each case has been carefully examined and I am confident, 
although not yet certain in every case, that the cause has been determined. The 
continuing analysis is expected to establish within the next few days that the causes 
have been correctly identified, and a subsequent memo will be written at that time. 
It is gratifying that only the first three anomalies are related to any program 
characteristic would could be construed as a deficiency, and these were known 
and accepted characteristics at the time the program was designed. 


1. Auto P66 removes the bulk of the forward velocity very quickly, but a residual 
error of about 0. 7 fps decays with a time constant of about 10 seconds. 

Cause; The pitch forward at the start of P66 causes the thrust direction filter 
of FINDCDUW to acquire a small error which decays with a time con¬ 
stant of about 10 seconds and produces a thrust pointing error during 
this interval. 


Cure; If warranted, the thrust direction filter could redesigned to remember 

the past attitude or thrust pointing direction so as to eliminate the bulk 
of the filter error due to attitude rate. 

2. About +2 fps variation in the rate of descent of P66 can occur even when P66 
is entered automatically. 

Cause: I am confident although not yet certain that the entire variation can be 

attributed to variation in the time-to-go of the last pass of P64, devi¬ 
ations of the terrain from the terrain model, noise in the radar, and 
other normal trajectory dispersions. Rate of descent variations were 
known and accepted at the time the auto-P66 program was designed. 

Cure: Variations could easily be avoided by initializing the command descent 

rate at 3 fps if P66 was entered automatically, and initializing the 
command at the current descent rate if P66 was entered by ROD switch 
manipulation. The disadvantage of initializing at 3 fps in the automatic 
case is that possible substantial descent rate variations at P64 terminus 
would be involuntarily corrected immediately starting P66 with the 
engine going to maximum or minimum throttle. With an astronaut who 
normally has his hand on the ROD switch, we should let him decide 
how to correct descent rate dispersions rather than forcing upon him 
an immediate correction. Consequently I conclude the system is cor¬ 
rectly designed and recommend against any such change. Also, the 
dispersions in P66 descent are nearly symmetrical about the nominal 
3 fps. Therefore we conclude the P64 target erasables are correct. 

3. Yaw error (defined as CDUY-CDUYD) of 1 degree or more persists for tens 
of seconds during P64 and P66. 

Cause: With the DAP deadband of 0. 3° and a phase plane logic containing a "flat" 

of 0. 8 , the DAP does nothing to correct an attitude error of up to 
1. 1° providing it computes that the yaw rate error, however slight, is 
such as to diminish the yaw error. There are several ways, too 
elaborate to describe here, in which the yaw error can be produced. 

The resolution of FINDCDUW's rate commands is much finer than the 
resolution of the angle commands, which in many cases causes the 
DAP to erroneously compute that the yaw rate error is such as to di¬ 
minish the yaw error; consequently the DAP does nothing and the error 
persists. 
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Cure: 


The flat was designed to facilitate transfer of U and V axes control to 
the trim gimbal. The trim gimbal does nothing for yaw, but the flat 
was retained in the yaw channel to preserve similarity with the other 
channels, the additional 0. 8° yaw error not seeming objectionable. 

With azimuth-redesignation granularity to be 1°, the 1. 1 yaw error 
may be objectionable, and perhaps the flat should be eliminated in yaw. 

4. The yaw angle diverges gradually from zero during most of P64 to about 2°, 
and diverges rapidly a few seconds prior to P64 terminus to about 4°. 

Cause: Cross-range dispersions in the initial velocity and Y axis velocity error 

produced by accelerometer bias is detected by the radar and produces 
a non-planar approach trajectory. Lowell Hull of Delco has pointed 
out that there is also an apparent Y axis velocity error due to trunca¬ 
tion of the landing site update. However, this effect is comparatively 
small and we have not established numerically that it can be responsi¬ 
ble for the apparent yaw-left bias. The cause of the sudden increase 
in the yaw rate a few seconds prior to the end of P64 has been traced 
to the algorithm which generates the window pointing command. The 
increase occurs as the LPD angle passes 65° and the algorithm switches 
from commanding the line-of-sight vector to commanding the Z axis 
of the guidance coordinate frame. The two command vectors would 
produce the same yaw angle except that the spacecraft is rolled about 
the Z axis by about + 0. 8° because the center of mass is not on the X 
axis. The roll suppresses the yaw until the window pointing command 
is switched, at which time the spacecraft yaws into alignment with the 
guidance coordinate frame. 

Cure: This is a normal characteristic of the descent guidance. Unless some¬ 

one can assert that such small yaw deviations are objectionable, 
nothing should be done. 

5. One bit-by-bit simulation hit the top of a hill about 1. 5 km short of the landing 
site while moving 47 m/s ( 105 mph). 

Cause: An initial down range error of 3000 m produced a substantial mismatch 

between the terrain and the modeled terrain. In addition, a series of 
restarts during the pitch-forward maneuver at the start of P64 caused 
the maneuver to be delayed about 8 seconds (the autopilot stops attitude 
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rates and sets to zero attitude rate commands (ZATTEROR ) during a 
restart). The delay in the maneuver caused the altitude to drop 70 meters 
below what would have occurred without the restarts, precisely the 
amount the trajectory would have otherwise cleared the hill. 

Cure: With noun 69, the down range dispersion will be much smaller, and 

with landing site redesignation to the nominal site, the terrain model 
will be matched to the terrain. 

6. Simulations are landing about two minutes earlier than TLAND. 

Cause: The operational trajectory has recently been slightly redesigned, and 

the corrected initialization has not yet been put in the simulations. 

Cure: We will shortly reinitialize to the new O. T. 

7. The time under throttle control during the braking phase was about 30 seconds 
longer than expected. 

Cause: One issue of the ’’Final H-3 Prelaunch Erasable Load Luminary 178” 

quoted RIGNZ as -1. 484979987 + 006 ft. The correct value is 
-1.464979987 + 006 ft. Consequently the engine was ignited about 4 
seconds early. 

Cure: Automate the process of generating these erasables to eliminate human 

error. Every landing mission except possibly 13 has had at least one 
human error in the erasable load. 
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